System and method for accessing directory services via an HTTP URL

ABSTRACT

Information is retrieved from a directory service via a Hyper Text Transport Protocol (HTTP) Universal Resource Locator (URL) query string which is parsed by a diverting module. The diverting module parses the HTTP URL query string into a plurality of portions. The diverting module constructs a directory service compatible query from the plurality of portions and requests information from the directory service with the directory service compatible query.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application Ser.No. 60/217881, entitled “Accessing Active Directory via URL”, filed onJul. 12, 2000.

FIELD OF THE INVENTION

The present invention relates generally to directory service access, andmore particularly to accessing a directory service via a Hyper TextTransport Protocol (HTTP) Universal Resource Locator (URL).

BACKGROUND OF THE INVENTION

A directory service is a central point in a computer or a computernetwork where network services, security services, applications, and thelike can inform other entities in the computer or network about theirservices, thus forming an integrated distributed computing environment.The current use of directory services may be classified into severalcategories. A “naming service” uses a directory as a source to locate anInternet host address or the location of a given server. A “userregistry” stores information of all users in a system composed of anumber of interconnected machines. The central repository of userinformation enables a system administrator to administer the distributedsystem as a single system image. Still another directory service is theMICROSOFT ACTIVE DIRECTORY directory service, a product of MicrosoftCorp. of Redmond, Wash., which allows a system administrator to manageusers, computers, printers, and other objects.

Conventional access to a directory service, such as a MICROSOFT ACTIVEDIRECTORY directory service is typically achieved by way of aLightweight Directory Access Protocol (LDAP) query string. For example,a MICROSOFT ACTIVE DIRECTORY directory service can be accessed usingLDAP application programming interfaces (APIs). However, using such APIsrequires an intimate knowledge of the APIs and requires programming tocall the APIs.

An MICROSOFT ACTIVE DIRECTORY directory service may also be accessedusing ACTIVE DIRECTORY Service Interfaces (ADSI). However, using ADSIalso requires programming.

Another method of accessing a directory service is the use of an LDAPquery string formatted as a Universal Resource Locator (URL) querystring (i.e., an LDAP URL) that is mapped to the directory service. TheLDAP URL includes portions referencing a host port, a scope, anattribute, a query filter, and optional extension mechanisms. The LDAPURL host port portion references a particular directory server. Thescope portion defines a search scope for the query. The search scopelimits the objects that are searched during a request for informationfrom a directory service. The attribute portion determines the attributevalue to return based on the query. The query filter portion operates ina manner similar to commonly known filters, such as the wildcard “*”.The optional extension mechanisms are implemented with APIs. This methodalso assumes that LDAP protocol will be used to for communication.

Importantly, the use of an LDAP URL to access information in a directoryservice behind a firewall is limited for the reason that many directoryservice owners (corporations, typically) are unwilling to allow externalaccess to LDAP ports on a firewall, mainly for reasons of security,resource utilization, and overhead issues. Nevertheless, such owners aremore likely willing to allow external access to Hyper Text TransportProtocol (HTTP) ports on the firewall.

Therefore, there is a need for access to a directory service via an HTTPport. More particularly, a need exists for a system and method foraccessing a directory service by way of an HTTP URL.

SUMMARY OF THE PRESENT INVENTION

The aforementioned need is satisfied by a system and method foraccessing a directory service via an Hyper Text Transport Protocol(HTTP) Universal Resource Locator (URL).

In the system and method, information is retrieved from a directoryservice via an HTTP URL query string which is parsed by a divertingmodule into a plurality of portions. The diverting module constructs adirectory service compatible query from the plurality of portions andsubmits the directory service compatible query to the directory service.

According to an aspect of the invention, data structure is implementedon a computer readable medium. The data structure used by the module mayreside on a server. The data structure comprises includes an HTTP URLquery string. The HTTP URL query string includes an HTTP portionrepresenting that the query string is an HTTP URL query string, ananchor point portion representing an anchor point within the directoryservice for a search to be conducted based on the query string, and apath and query portion defining a search scope based on the anchor pointfor the search in the directory service.

According to another aspect of the present invention, a system retrievesinformation from a directory service into an access device via an HTTPURL query string. The system includes a server connected to the accessdevice through an HTTP connection, the server for receiving the querystring, for parsing the received query string into a friendly nameportion, and for determining whether the friendly name portion is amember of a predetermined set of friendly names. The system furtherincludes a diverting module for receiving the query string from theserver if the friendly name portion is a member of the predetermined setof friendly names, for parsing the received query string, forconstructing a directory service compatible query based on the parsedstring, and for forwarding the directory service compatible query to thedirectory service.

The above-listed features, as well as other features, of the presentinvention will be more fully set forth hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is further described in the detailed descriptionthat follows, by reference to the noted drawings by way of non-limitingexamples of exemplary embodiments of the present invention, in whichlike reference numerals represent similar parts throughout the severalviews of the drawings, and wherein:

FIG. 1 is a block diagram of an exemplary directory service with whichthe present invention may be employed;

FIG. 2 is a block diagram of a system that accepts an HTTP URL andformulates a directory service compatible query for the directoryservice of FIG. 1 in accordance with an embodiment of the presentinvention;

FIG. 3 is a block diagram of a data structure of an HTTP URL for beingsubmitted to the system of FIG. 2 in accordance with an embodiment ofthe present invention;

FIG. 4 is a flow chart of an exemplary method employing the system ofFIG. 2 and the data structure of FIG. 3 in accordance with an embodimentof the present invention; and

FIG. 5 is a block diagram representing a general purpose computer systemin which aspects of the present invention and/or portions thereof may beincorporated.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 5 and the following discussion are intended to provide a briefgeneral description of a suitable computing environment in which thepresent invention and/or portions thereof may be implemented. Althoughnot required, the invention is described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer, such as a client workstation or a server.Generally, program modules include routines, programs, objects,components, data structures and the like that perform particular tasksor implement particular abstract data types. Moreover, it should beappreciated that the invention and/or portions thereof may be practicedwith other computer system configurations, including hand-held devices,multi-processor systems, microprocessor-based or programmable consumerelectronics, network PCs, minicomputers, mainframe computers and thelike. The invention may also be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules may be located in both local and remotememory storage devices.

As shown in FIG. 5, an exemplary general purpose computing systemincludes a conventional personal computer 120 or the like, including aprocessing unit 121, a system memory 122, and a system bus 123 thatcouples various system components including the system memory to theprocessing unit 121. The system bus 123 may be any of several types ofbus structures including a memory bus or memory controller, a peripheralbus, and a local bus using any of a varietv of bus architectures. Thesystem memory includes read-only memory (ROM) 124 and random accessmemory (RAM) 125. A basic input/output system 126 (BIOS), containing thebasic routines that help to transfer information between elements withinthe personal computer 120, such as during start-up, is stored in ROM124.

The personal computer 120 may further include a hard disk drive 127 forreading from and writing to a hard disk (not shown), a magnetic diskdrive 128 for reading from or writing to a removable magnetic disk 129,and an optical disk drive 130 for reading from or writing to a removableoptical disk 131 such as a CD-ROM or other optical media. The hard diskdrive 127, magnetic disk drive 128, and optical disk drive 130 areconnected to the system bus 123 by a hard disk drive interface 132, amagnetic disk drive interface 133, and an optical drive interface 134,respectively. The drives and their associated computer-readable mediaprovide non-volatile storage of computer readable instructions, datastructures, program modules and other data for the personal computer120.

Although the exemplary environment described herein employs a hard disk,a removable magnetic disk 129, and a removable optical disk 131, itshould be appreciated that other types of computer readable media whichcan store data that is accessible by a computer may also be used in theexemplary operating environment. Such other types of media include amagnetic cassette, a flash memory card, a digital video disk, aBernoulli cartridge, a random access memory (RAM), a read-only memory(ROM), and the like.

A number of program modules may be stored on the hard disk, magneticdisk 129, optical disk 131, ROM 124 or RAM 125, including an operatingsystem 135, one or more application programs 136, other program modules137 and program data 138. A user may enter commands and information intothe personal computer 120 through input devices such as a keyboard 140and pointing device 142. Other input devices (not shown) may include amicrophone, joystick, game pad, satellite disk, scanner, or the like.These and other input devices are often connected to the processing unit121 through a serial port interface 146 that is coupled to the systembus, but may be connected by other interfaces, such as a parallel port,game port, or universal serial bus (USB). A monitor 147 or other type ofdisplay device is also connected to the system bus 123 via an interface,such as a video adapter 148. In addition to the monitor 147, a personalcomputer typically includes other peripheral output devices (not shown),such as speakers and printers. The exemplary system of FIG. 12 alsoincludes a host adapter 155, a Small Computer System Interface (SCSI)bus 156, and an external storage device 162 connected to the SCSI bus156.

The personal computer 120 may operate in a networked environment usinglogical connections to one or more remote computers, such as a remotecomputer 149. The remote computer 149 may be another personal computer,a server, a router, a network PC, a peer device or other common networknode, and typically includes many or all of the elements described aboverelative to the personal computer 120, although only a memory storagedevice 150 has been illustrated in FIG. 12. The logical connectionsdepicted in FIG. 12 include a local area network (LAN) 151 and a widearea network (WAN) 152. Such networking environments are commonplace inoffices, enterprise-wide computer networks, intranets, and the Internet.

When used in a LAN networking environment, the personal computer 120 isconnected to the LAN 151 through a network interface or adapter 153.When used in a WAN networking environment, the personal computer 120typically includes a modem 154 or other means for establishingcommunications over the wide area network 152, such as the Internet. Themodem 154, which may be internal or external, is connected to the systembus 123 via the serial port interface 146. In a networked environment,program modules depicted relative to the personal computer 120, orportions thereof, may be stored in the remote memory storage device. Itwill be appreciated that the network connections shown are exemplary andother means of establishing a communications link between the computersmay be used.

Turning now to FIG. 1, it is seen that such drawing represents anexemplary directory service hierarchy. The following discussion of thenaming hierarchy in FIG. 1 is merely illustrative and is not intended tobe limiting. As shown in FIG. 1, the directory service 10 includes anumber of objects, with each object represented by a unique name and allof the objects being organized into a hierarchical structure. Thus, forexample, the object at the top of the hierarchical structure is named A,which is typically referred to as the “root”. Object A has two“children”, objects B and C, and objects B and C resides one level belowthe root and dependent from object A. Object B has two “children”,objects E and F, and objects E and F reside two levels below the rootand dependent from object B. Object F has one “child”, object H, andobject H resides three levels below the root and dependent from objectF. A particular object thus may be a “parent” of one or more childobjects. An object is considered a “parent” if it is located in a nexthigher level than a “child” object in the hierarchy and the child objectdepends from such parent object. Objects on the same level of thehierarchy, with the same parent are considered siblings. In this manner,a system administrator may organize objects into a hierarchicalstructure.

Each object is of a particular object class. For example, there may be acomputer object class, a printer object class, and a user object class.As specific examples, object B may represent a printer and may beconfigured as a printer object class, object C may represent a computerand may be configured as a computer object class, and object E mayrepresent a user and may be configured as a user object class. In thismanner, a system administrator may organize objects by class in additionto a hierarchical structure.

Each object may contain attributes, and each attribute may contain avalue associated with the attribute. For example, an attribute of a userclass object may be a phone number. The value of the attribute may beset to a phone number of that particular user. In this manner, a systemadministrator may include information regarding objects in a directoryservice.

The directory service 10 hierarchy may be organized in any predefinedmanner, for example by the system administrator. Each object in thedirectory service is typically uniquely identified in the directory anduniquely named for a given parent. Additionally, some directoryservices, such as the MICROSOFT ACTIVE DIRECTORY include aUserPrincipalName attribute for user class objects. Typically, theUserPrincipalName attribute is set to a value of an e-mail address, forexample, JohnSmith@microsoft.com.

Referring now to FIG. 2, there is shown an exemplary system 11 foraccessing the directory service 10 of FIG. 1 based on an HTTP URL querystring in accordance with an embodiment of the present invention. Asshown in FIG. 2, the system 11 includes a server 25 and a divertingmodule 30. As may be appreciated, the system 11 receives the HTTP URLquery string from an access device 15 by way of an HTTP port 21 on afirewall 20 associated with the server 25, and is coupled to thedirectory service by way of the diverting module 30. In one embodiment,the server 25 comprises the diverting module 30.

The access device 15 may be a web browser, a cellular phone, a netappliance, or any other device suitable for entering an HTTP URL that isto be delivered to the server 25. Access devices 15 are generally knownor should be apparent to the relevant public and therefore need not bedescribed herein in any detail. Thus, the access device 15 may be anyparticular access device without departing from the spirit and scope ofthe present invention. In one embodiment, the access device 15 is apersonal computer running a MICROSOFT INTERNET EXPLORER web browser, aproduct of Microsoft Corp. of Redmond, Wash., or the like.

The access device 15 may access the system 11 by an appropriateconnection, including a direct connection, an Ethernet connection, anIntranet connection, an Internet connection, a dialup connection, or thelike. As shown in FIG. 2, the connection with the system 11 is achievedby way of the firewall 20, so the access device 15 is presumablyexternally located with respect to the system 11. Nevertheless, theaccess device 15 may also be internally located so that the firewall 20is not necessary without departing from the spirit and scope of thepresent invention.

Server 25 and access device 15 can communicate with each other throughthe firewall 20 (if present) via any mutually agreeable protocol, suchas HTTP, for example. Firewalls 20 and servers 25 are generally known orshould be apparent to the relevant public and therefore need not bedescribed herein in any detail. Thus, the firewall 20 may be anyparticular firewall and the server 25 may be any particular serverwithout departing from the spirit and scope of the present invention. Inone embodiment, the server 25 is an Internet Information Server (IIS).

The HTTP port 21 may represent any port through which HTTP communicationis enabled. The HTTP port 21 may also represent the default port forcommunicating web pages with client browsers. In one embodiment, theaccess device 15 is connected to the server through an HTTP port 21 onthe firewall 20.

The firewall 20 is a security system (hardware and/or software) thatisolates resources of the system 11 and beyond from objects outside ofthe system 11. Isolated resources are characterized as inside thefirewall, and external equipment is considered outside the firewall.Typically, the firewall 20 serves as a security enclosure around aprivate LAN of computers and associated peripherals. Generally, thefirewall 20 allows for inside objects to request and receive connectionsto outside objects (e.g., for inside applications to access outsideinternet nodes, etc.) but prevents outside objects from originatingsimilar connections unless otherwise determined to be allowable.

The directory service 10 is generally known or should be apparent to therelevant public and therefore need not be described herein in anydetail. The directory service 10 may be any particular directory servicewithout departing from the spirit and scope of the present invention. Inone embodiment, the directory service 10 is the MICROSOFT ACTIVEDIRECTORY directory service. The directory service 10 is connected tothe server 25 over a conventional data link, such as for example, anEthernet connection or a direct connection from the server 25.

Typically, a server such as the server 25 receives a query for thedirectory service 10 where such query is already in a form amenable tothe directory service 10. For example, where the directory service 10can receive and process an LDAP query string, the server 25 wouldtypically receive a query for the directory service 10 in the form ofsuch LDAP query string.

Importantly, in the present invention, the server 25 receives a queryfor the directory service 10 where the query is in one form (e.g., anHTTP URL query string) and where the directory service 10 is expectingthe query to be in another form (e.g., an LDAP query string).Accordingly, in one embodiment of the present invention, the system 11includes the diverting module 30 for receiving the query string for thedirectory service 10 from the server 25 for reformatting the querystring into a form amenable to the directory service 10, and for sendingthe reformatted query string to the directory service 10.

In particular, in an embodiment of the present invention, the divertingmodule 30 receives the query string from server 25, parses the querystring, forms the reformatted query string, and then sends thereformatted query string to the directory service 10. Once the directoryservice 10 gathers appropriate information based on the receivedreformatted query string, such information is sent to the server 25perhaps by way of the diverting module 30. As may be appreciated eitherthe server 25 or the diverting module 30 may format the information in aform amenable to the access device 15. For example, the information maybe formatted into a Hyper Text Markup Language (HTML) web page,eXtensible Markup Language (XML), or the like, to be displayed on thebrowser of the access device 15.

In one embodiment of the present invention, the query string from theaccess device 15 is an HTTP URL query string having a particular datastructure that may be appreciated by the diverting module 30 in thecourse of reformatting such HTTP URL query string into the form expectedby the directory service 10.

FIG. 3 shows a block diagram of such a data structure 35 in accordancewith an embodiment of the present invention. As shown in FIG. 3, thedata structure 35 of the query string includes an HTTP portion 40, aserver name portion 45, a friendly name portion 50, a path and queryportion 60, and an optional parameters portion 65. Thus, an exemplaryHTTP URL query string may be given by:

-   http://servername/friendlyname/path-and-query?parameters    As may be appreciated, such HTTP URL query string is to be sent to    the server 25 in the manner of a typical HTTP request sent to a    typical HTTP server.

In one embodiment of the present invention, the server 25 behind thefirewall 20 receives the HTTP URL query string by way of an HTTP port onthe firewall 20 and recognizes that the request is to be diverted to thedirectory service 10 by way of the diverting module 30. Such recognitionmay for example occur based on the server name portion 45 and/or thefriendly name portion 50 of the query string, although other recognitionmethodologies may be employed without departing from the spirit andscope of the present invention.

Upon receiving the diverted query string, the diverting module 30 parsesand deconstructs such HTTP URL query string into the various portions50-65, constructs the aforementioned reformatted query string, and thentransmits same to the directory service 10.

Portions 40-65 are discussed in turn as follows. The HTTP portion 40contains information representing the beginning of an HTTP URL string.For example, the HTTP portion 40 may contain the string “http://”.

The server name portion 45 contains information representing any servername that can be resolved to an Internet Protocol (IP) address. Theserver name links the access device 15 to a server, such as server 25.For example a server name portion 45 may be “microsoft.com”, which wouldmap the access device 15 to the server 25 associated with the name“microsoft.com”.

The friendly name portion 50 contains information representing to theserver 25 that the query string is to be diverted to the divertingmodule 30 for parsing. The friendly name may be any name that triggersthe diverting module 30 to parse the query string as a request forinformation from the directory service 10. In one embodiment, the server25 compares the friendly name against a predetermined set of names. Ifthe friendly name is included in the predetermined set of names, thenthe server 25 diverts the query string for parsing by the divertingmodule 30. If not, then the query string is processed as a conventionalquery string by the server 25. A friendly name is not necessary as adiverting mechanism, for example, a server 25 may be dedicated todirectory service 10.

In another embodiment, the diverting module 30 parses the query stringand if the friendly name is not included in the predetermined set ofnames, then the diverting module 30 diverts the query string to theserver 25.

In one embodiment of the present invention, the friendly name portion 50and the friendly name therein also anchors a search scope to apredetermined anchor point in the directory service 10. The friendlyname may also serve other purposes including improving queryperformance, filtering HTTP verbs, canonicalizing long naming, andlimiting users to a subset of objects that are pertinent to theirqueries.

As may be appreciated, an anchor point is an object within the directoryservice 10 from which the search scope is defined. For example, in thedirectory service 10 of FIG. 1, a partial query string of:

-   http://microsoft.com/consultants    maps to the server 25 with the name “microsoft.com”, and sets an    anchor point, within a directory service 10 associated with the    server 25, according to a predetermined criteria associated with the    friendly name “consultants”. For example, the anchor point for    “consultants” may be set at object B, as shown in FIG. 1. In one    embodiment of the present invention, no searching takes place on    objects higher in the directory service 10 than the anchor point.    Here, then, with ‘consultants’ as the anchor point, the object A    will not be included in the search scope. In this manner, a query    can be limited to selected branches of the directory service 10.

The path and query portion 55 contains information referencing the pathto be searched and query options to further define the search scope. Thepath sub-portion of the path and query portion 55 defines the boundaryor scope of the search scope with respect to the anchor point. Thesearch scope may be defined to include the anchor point itself, toexclude the anchor point but to include one level below the anchorpoint, to include the anchor point and the entire subtree below theanchor point, or the like. The query sub-portion of the path and queryportion 55 modifies the search with commonly known filters, such as awildcard “*” and a slash “/”, as will be described further below.

In one embodiment of the present invention, a path and query of “/*”searches the children of the anchor point, a path of “/objectX/*”searches the children of objectX, wherein objectX is a child of theanchor point, and a path of “/objectX//” searches the subtree ofobjectX, wherein objectX is a child of the anchor point.

For example, and with respect to the directory service 10 of FIG. 1, apartial query string of:

-   http://microsoft.com/consultants/*    searches the children of B, which are object E and object F.    Likewise, a query string of:-   http://microsoft.com/consultants/F/*    searches the children of F, which is object H. Similarly, a query    string of:-   http://microsoft.com/consultants//    searches the sub-tree of B, which includes object B, object E,    object F, and object H, given that object B is the anchor point    associated with ‘consultants’.

In one embodiment of the present invention, a search may be based on anattribute name by including a path and query of “attribute=attributevalue”.

For example, and with respect to the directory service 10 of FIG. 1, apartial query string of:

-   http://microsoft.com/consultants//givenName=John    searches the sub-tree of B, which includes object B, object E,    object F, and object H. Additionally, the query sub-portion of    “givenName=John” searches all objects within the search scope as    described above, and searches for an attribute of “givenName” with a    value of “John”.

Similarly, searches may be based on object class by including a querysub-portion of “.object class”. For example, a query sub-portion of“*.user” searches for all objects in the directory service with anobject class of “user” within the defined search scope.

For example, and with respect to the directory service 10 of FIG. 1, apartial query string of:

-   http://microsoft.com/consultants//*.user    searches the sub-tree of B, which includes object B, object E,    object F, and object H. Additionally, the query sub-portion of    “*.user” searches for all objects within the search scope as    described above, and searches for all objects of object class    “user”.

Additionally, a wildcard may be used in query portion. For example, aquery string of:

-   http://microsoft.com/consultants//John*.user    searchers the sub-tree of B, which includes object B, object E,    object F and object H. Additionally, the query sub-portion of    “John*.user” searchers for all objects within the search scope as    described above, and searches for all objects of object class “user”    and with its object name starts with “John”.

The parameters portion 65 may contain information referencing optionalparameters. Such optional parameters may, for example, modify defaultparameter values, such as PageSize, which specifies the page size toreturn, and TimeOut, which determines how long to wait for a responsebefore timing out. Also, the parameters portion 65 may be used torequest an attribute be returned to server 25 from the directory service10, as described in more detail below.

As discussed above, the HTTP URL request may be responded to by thesystem 25 with an HTML page. In addition, the response may be in an XMLformat. In one embodiment of the present invention, a parameter in theparameters portion 65 of the HTTP query string may be set to specify thetype of response. For example, a parameter may be set to request a HTMLformat, or other form of documents. Optionally, the response may includeerror messages.

In one embodiment of the present invention, the parameters portion 65contains information referencing an attribute value to be returned. Forexample, the parameters portion 65 may be specified as“?attr=attributename” in the HTTP query string. If a particularattribute value is to be returned, as triggered by the “?attr=” portionof the query string, the directory service 10 returns the value of theattribute. If no attribute is to be returned, the directory service 10returns a default set of attributes for each object of the definedsearch, such as the URL, name, and class of the object. For example, aquery string of:

-   http://microsoft.com/consultants/?attr=phonenumber,title    returns the value in the attribute phone number and title of object    B, if such attribute exists for the object. Referring now to FIG. 4,    a method of operating the system 25 to access a directory service 10    is shown. As seen at step 200, the access device 15 sends an HTTP    URL query string to the server 25. This step is similar to    conventional server access via an HTTP URL query string. For    example, the HTTP URL query string may be-   http://microsoft.com/consultants//sn=Smith-   The query string is received at the http port 21 and firewall 20 and    passes through to the server 25 as a conventional HTTP URL query    string.

At step 205, the server 25 detects that the query string is to bediverted to diverting module 30. In this step, the server 25 may parsethe friendly name portion 50 of the query string and compare thefriendly name portion against a predetermined set of names, as describedabove. If the friendly name is in the predetermined set of names, thesystem proceeds to step 210. Otherwise, the server 25 processes the HTTPURL as a conventional HTTP URL.

At step 210, the server 25 diverts the query string by sending the querystring to the diverting module 30. At step 220, the diverting module 30receives the query string and at step 230, the diverting module 30parses the query string. Particularly, the diverting module 30 parsesthe query string to resolve a friendly name portion 50 at step 240, apath and query portion 55 at step 250, and a parameters portion 65 atstep 270.

At step 240, the diverting module 30 parses the query string into afriendly name portion 50, as the string “consultants” and an anchorpoint is set according to a predetermined anchor point list associatedwith the friendly name. For example, the anchor point associated withthe friendly name “consultants” may be object B in the directory service10, as shown in FIG. 1.

At step 250, the diverting module 30 parses the query string into a pathsub-portion as the string “//”. This sets the search scope to the entiresub-tree of the anchor point. In the directory service 10 of FIG. 1,with an anchor point of object B. the search scope includes objects B,E, F, and H. The diverting module 30 parses the query string into aquery sub-portion as the string “sn=Smith”. This sets the querysub-portion to search for an attribute of “sn”, or surname, with anattribute value of “Smith”.

At step 270, the diverting module 30 parses the query string into aparameters portion 65, as a null string. Thus, no optional parametersare included in the query string and default values are to be used.

At step 280, the diverting module 30 builds a reformatted query that iscompatible with the directory service 10. Particularly, the reformattedquery searches the search scope determined in steps 240 and 250 and withthe parameters determined in step 270. For example, the diverting module30 builds a reformatted query that accesses the directory service 10 andsearches user objects of objects B, E, F, and H for each object havingan attribute of “sn” with an attribute value of “Smith”.

At step 290, the diverting module 30 forwards the reformatted query tothe directory service 10 and at step 300, the directory service 10replies to the reformatted query. The reply may be, for example, an XMLformatted response or an LDAP response. At step 310, the divertingmodule will reformat the response from directory service 10 to a formatthat is expected by the access devices 15, for example HTML or XML. Atstep 320, the access device 15 receives the information from thedirectory service 10 by way of server 25 and perhaps the divertingmodule 30.

Thus, in the present invention, a web page may be constructed with HTTPURL links tailored to access information in the directory service 10,and a user of the web page may access such information without beingconcerned with the actual construction of the links or understanding ofAPIs to access the directory service 10. Therefore, the presentinvention provides an HTTP URL formatted query string employed to gainaccess to a directory service 10.

It is noted that the foregoing examples have been provided merely forthe purpose of explanation and are in no way to be construed as limitingof the present invention. While the invention has been described withreference to preferred embodiments, it is understood that the wordswhich have been used herein are words of description and illustration,rather than words of limitations. Further, although the invention hasbeen described herein with reference to particular elements, steps,and/or embodiments, the invention is not intended to be limited to theparticulars disclosed herein; rather, the invention extends to allfunctionally equivalent structures, methods and uses, such as are withinthe spirit and scope of the appended claims. Those skilled in the art,having the benefit of the teachings of the present disclosure, mayeffect numerous modifications thereto and changes may be made withoutdeparting from the scope and spirit of the invention in its aspects.

1. A data structure implemented on a computer readable medium, the datastructure comprising a Hyper Text Transport Protocol (HTTP) UniversalResource Locator (URL) query string including: an HTTP portionrepresenting that the query string is an HTTP URL query string; ananchor point portion representing an anchor point within the directoryservice for a search to be conducted based on the query string; and apath and query portion defining a search scope based on the anchor pointfor the search in the directory service.
 2. The data structure of claim1 wherein the query string further includes a server name portionrepresenting a server name through which the directory service isaccessible.
 3. The data structure of claim 1 wherein the search scope isdefined relative to the anchor point in the directory service.
 4. Thedata structure of claim 1 wherein the query string further includes aparameters portion representing an attribute to be returned based on thesearch.
 5. A computer readable medium having stored thereon a datastructure comprising a Hyper Text Transport Protocol (HTTP) UniversalResource Locator (URL) query string including: an HTTP portionrepresenting that the query string is an HTTP URL query string; ananchor point portion representing an anchor point within the directoryservice for a search to be conducted based on the query string; and apath and query portion defining a search scope based on the anchor pointfor the search in the directory service.
 6. The medium of claim 5wherein the query string further includes a server name portionrepresenting a server name through which the directory service isaccessible.
 7. The medium of claim 5 wherein the search scope is definedrelative to the anchor point in the directory service.
 8. The medium ofclaim 5 wherein the query string further includes a parameters portionrepresenting an attribute to be returned based on the search.
 9. Amethod of retrieving information from a directory service via a HyperText Transport Protocol (HTTP) Universal Resource Locator (URL) querystring, the method comprising: parsing the query string into an anchorpoint portion representing an anchor point within the directory servicefor a search to be conducted based on the query string; parsing thequery string into a path and query portion defining a search scope basedon the anchor point for the search in the directory service;constructing a directory service compatible query from the plurality ofparsed portions; and forwarding the constructed query to the directoryservice, wherein the directory service conducts the search based uponthe forwarded query to produce search results.
 10. The method of claim 9further comprising receiving the search results from the directoryservice.
 11. The method of claim 10 comprising receiving the searchresults from the directory service in a Hyper Text Markup Languageformat.
 12. The method of claim 10 comprising receiving the searchresults from the directory service in an eXtensible Markup Languageformat.
 13. (canceled)
 14. The method of claim 9 further comprisingparsing the HTTP URL query string into a parameters portion representingan attribute to be returned based on the search.
 15. A computer-readablemedium having stored thereon computer executable instructions forretrieving information from a directory service via a Hyper TextTransport Protocol (HTTP) Universal Resource Locator (URL) query string,the instructions being organized into modules including: a first modulefor parsing the query string into an anchor point portion representingan anchor point within the directory service for a search to beconducted based on the query string; a second module for parsing thequery string into a path and query portion defining a search scope basedon the anchor point for the search in the directory service; a thirdmodule for constructing a directory service compatible query from theplurality of parsed portions; and a fourth module for forwarding theconstructed query to the directory service, wherein the directoryservice conducts the search based upon the forwarded query to producesearch results.
 16. The medium of claim 15 further comprising a fifthmodule for receiving the search results from the directory service. 17.The medium of claim 16 wherein the fifth module receives the searchresults from the directory service in a Hyper Text Markup Languageformat.
 18. The medium of claim 16 wherein the fifth module receives thesearch results from the directory service in an eXtensible MarkupLanguage format.
 19. (canceled)
 20. The medium of claim 15 furthercomprising a fifth module parsing the HTTP URL query string into aparameters portion representing an attribute to be returned based on thesearch.
 21. A system for retrieving information from a directory serviceinto an access device via a Hyper Text Transport Protocol (HTTP)Universal Resource Locator (URL) query string comprising: a serverconnected to the access device through an HTTP connection, the serverfor receiving the query string, for parsing the received query stringinto a friendly name portion, and for determining whether the friendlyname portion is a member of a predetermined set of friendly names; and adiverting module for receiving the query string from the server if thefriendly name portion is a member of the predetermined set of friendlynames, for parsing the received query string, for constructing adirectory service compatible query string based on the parsed string,and for forwarding the directory service compatible query string to thedirectory service.
 22. The networked computer system of claim 21 whereinthe server comprises the diverting module.